REMARKS 

In response to Examiner's Office Action of March 25, 
2004, Applicant would now respond with the following comments. 

As a preliminary note, the Examiner rejected claims I'- 
ll for double-patenting over Applicant's prior case, 6,571,283, 
claim 27. However, there is no such claim 27 in that case, and a 
fax was sent to the Examiner to indicate this. 

Note that the " prior patent " cited (6,571,283), 
involves an estimator program to perform method steps 
for estimating the optimum operating server farm 
designed to serve a particular number of clients "n". 

But note, the present invention is an estimator 
program performing method steps for " estimating 
parameters " of the optimum operating server 
metafarm designed to serve a particular large 
number of clients "L". 

Note, clause (d) of Applicant's claim 1 which 
indicates using an optimization technique to 
find the optimum value of the optimization 
parameter (parameters) • 

The present application involves a large number of 
clients "L" working with the configuration of a 
metafarm (not just a single Server Farm) . 

The prior patent (6,571,283) involves estimating the 
optimum operating server farm designed to serve a 
particular number of clients "n" . 
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Thus, there is a substantial difference in operating 
functionality and scope (metafarm) of operation. 
Consequently, Applicant would traverse Examiner's 
conclusion that this application is not patentability 
distinct from 6,571,283. There is a substantial 
difference in the scope of applicability. 

For example: 

The laws and rules of classical physics in the normal domain 
do not apply to the atomic domain and quantum fields. 

Likewise, a server farm of a nominally small number of users 
does not completely and properly apply to a huge metafarm 
with huge numbers of users (10,000+). 

Note, that the claim 18 (dependent on claim 12) of 
Applicant's prior patent 6,571,283, indicates the step (d5), which 

includes the step of (d5a) continuing the optimization 

procedure if the optimum number for the server farm size is not 
yet determined by repeating step (d2) through (d5) with another 
value of said optimization parameter from the domain. 

A. Examiner rejects claim 1 for obviousness over Primak, U.S. 
Patent 6,389,448 in view of Adelman, U.S. Patent 6,006,259. 

Primak does not explicitly teach the server farm as a 

metafarm but Examiner says Adelman teaches the 

server farm as plurality of "cluster members 11 • 

Primak does not explicitly teach the Server Farm as a 

metafarm but Examiner intimates that Adelman 

teaches the metafarm as "plurality of cluster members" • 
A cluster of server farms does not teach the design of 
an optimum met af ana. Examiner says he can combine the 
teaching of Primak and Adelman to teach Applicant's 
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system but this would not apply when one is 

designing from scratch to form an optimum configuration 
for a huge client base. 

Examiner contends he can combine the teaching of Primak 
with that of Adelman to teach Applicant's system. 
Applicant would traverse this conclusion. Applicant 

would now ask of Examiner just how would Adelman 

fit in to contribute to Primak so as to enable a 
designer to establish optimum metafarms as in 
Applicant's Figures 2 and 3? 

It should be noted that the Primak reference involves a 
system and technique for balancing or distributing load between 
the servers in a server cluster -- thus, it provides a network 
load balancing system which is highly scaleable and optimizes 
packet throughput by dynamically distributing the load between 
the servers in a server cluster. 

This should be contrasted very emphatically with 

Applicant's configuration which involves an estimator program 

that performs method steps for estimating parameters of the 
optimum operating server met a farm designed to serve a particular 
large number of clients "L" . This is an advance design 
configuration and not , as in Primak, a load balancing system of 
an already existing configuration! 

The concept of estimating parameters for a metafarm is 
quite different from the Primak concept of already 
having an established set of server clusters, and then 
balancing the loads between these clusters. Quite a 
different proposition entirely. 
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In regard to Applicant's claims 2 and 3, the Examiner 
has cited the Primak reference at column 4, lines 10-20. 

Now, to summarize Primak column 4, lines 10- 

20, we see that at line 12 the agent 

program 14 can collect the availability 
information by monitoring one or more the 
servers internal conditions which affect the 
server's ability to establish connections 
with client computer 60. The monitored 
condi t ions may inc lude but are not 1 imi t ed 
to, the server's processing (or CPU) 
capacity, CPU load, number of concurrent 
processes or tasks being performed, and the 
number of existing connections. 

Now, how these factors described in Primak can ever 
cover the substance of Applicant's claims 2 and 3 is 
not understandable? For example, in Applicant's claim 
2 there exists the following: — 

(al) selecting for inputs a particular number of 
clients "L" for utilizing said server metafarm; 

(a2) selecting for input a maximum single server 
workload of users "P"; 

(a3) selecting for input a Mean Time To Repair 
Value (MTTR) for a single server; 

(a4) selecting for input a Mean Time To Failure 
(MTTF) for a single server. 
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It should be noticed that these various 
claimed clauses do not correlate with the 
Primak statements of column 4, lines 10-20. 

Now, further regarding Applicant's claim 3, where the 
Examiner has cited Primak column 4, lines 10-20, in 

regard to Applicant's clause (bl) which states: 

selecting a number of server farms that make up a 
server met af arm which is any natural integer number of 
servers, wherein each server farm is the same size in 
number of servers as each other server farm. 

Here, it should be noted that there is 
nothing in Primak column 4, lines 10-20 which 
involves developing a design configuration 
which selects the " number " of server farms 
that make up a server metafarm. 

Primak i s concerned with an already existing 
configuration and attempting to analyze each of the 
servers in order to do the proper amount of load 
balancing. This is quite a different function from that 
achieved in Applicant 1 s system. 

Thus, Examiner's claim that Primak teaches the 
particular number of clients "L" as the number of concurrent 
processes or tasks cannot be substantiated. 

Then, regarding Examiner's statement on Applicant's 
claim 3, where Examiner contends that Primak teaches the number 
of server farms, and the number of concurrent processes or tasks 

being performed cannot be substantiated since Applicant is 

dealing with the establishment of an " optimum " operating server 
metafarm, and the steps for estimating the parameters thereof. 
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There is no such purpose or functionality in 
the Primak cited reference. 

Further, in regard to the Examiner's assertion that the 
Adelman reference can be combined with the Primak reference to 
establish the functionality of Applicant's systems purposes and 
configuration, here again, Applicant would controvert this 
conclusion since it has already been well-established that it is 
improper for an Examiner to cite a second reference as being 
capable of inclusion into a first reference when the first 
reference does not suggest or indicate that such technology of 
the second reference could possibly be combined into the first 
reference. 

For example, in the case of In re Jones , 958 Fed. 2d, 
p. 347, 21 USPQ2d, pp.1941, 1943 (Fed.Cir 1992), it was stated as 
follows : 

Before the PTO may combine the disclosures of two 
or more prior art references in order to establish 
prima facie obviousness, there must be some 
suggestion for doing so found either in the 
references themselves or in the knowledge 
generally available to one of ordinary skill in 
the art. 

Further, in the case of Uniroyal, Inc. v. Rudkin-Wiley 
Corp. , 837 F.2d p. 1044, and 5 USPQ2d, p. 1434 (Fed.Cir 1988), it 
was stated: — 

When prior art references require a selected 
combination to render obvious a subsequent 
invention, there must be some reason for the 
combination other than the hindsight gleaned from 
the invention itself. Something in the prior art 
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as a whole must suggest desirability, and thus, 
the obviousness of making the combination. It is 
impermissible to use the claims as a frame and the 
prior art references as a mosaic to piece together 
a facsimile of the claimed invention. 

Where Examiner has stated that the Primak reference 
teaches the redundancy factor that should be minimized, citing at 
Primak column 5, lines 10-20, and Primak column 4, lines 10-20, 
it will be noted that Primak column 5, lines 10-20 is a very 
generalized discussion regarding the sub range for each server 
being continuously recalculated so that the size of each server's 
sub range is in proportion to the server's availability . . . . 
so that, for example, about 30% of all connections being accepted 
by a server would follow as a result of a server having 30% of 
the total availability of a server cluster. 

Now, compare this to Applicant's Figs. 2 and 
3, by which one can determine availability of 
a met af arm and the Mean Time To Failure of a 
metafarm. Note how this applies to 
Applicant's Fig. 1 involving a server 
metafarm which involves multiple numbers of 
server farms , that it is possible to perform 
steps to estimate the parameters of the 
" optimum " operating server farm designed to 
serve a large number of clients "L". 

Primak is not involved with an optimum 
server metafarm and its parameters. 

Note also, that at page 6 of Applicant's original 

specification at line 20 onward, where it states: at the same 

time this (previous) method had some technical limitations. The 
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original assumption that the reliability of the workload 
balancing mechanism is much higher than the reliability of a 
single server running applications becomes questionable, if the 
server farm size exceeds 100-120 servers. 

This particular problem arises in the situation where a 
very large number of users "L", say 10,000, 50,000 or 

100,000 users are involved the presently described 

new method improves server farm availability by using 
so-called metafarms divided into several server farms 
with a workload balancing mechanism that distributes 
workload as between the server farms and as between the 
servers that make up the server farms . . . . The 
metafarm design (unlike server farm design) may involve 

a new parameter the number of server farms of equal 

size that make up a server metafarm. The number of 
server farms can be used as one of the server metafarm 
optimization parameters. 

B. Regarding Applicant's claim 2, Examiner says Primak teaches 
the particular number of clients "L" as the number of concurrent 

processes or tasks being formed in Primak column 4 lines 10-20 

a TfiftviimiTn single server workload of uses — CPU capacity, CPU 
load, the number of existing connections, at Primak column 4, 
lines 10-20. 

Here, we should differentiate clients L from 
so-called tasks of Primak. 

C. Regarding Applicant's claim 3, Examiner contends that Primak 
teaches the number of server farms, the number of servers as the 
number of concurrent processes or tasks being performed at column 
4, lines 10-20. This does not correlate to Applicant's claim 3. 
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D. In claim 4, Examiner contends that Primak teaches a 
redundancy factor having an interval between 0 and 100%, and the 
entire range could result in about 30%, in Primak column 5 lines 
10-20. But note that Applicant's method is an entire combination 
of interrelated steps and not just one element plucked from a 
cited reference. 

E . Examiner says our claim 5 is an apparatus claim 
corresponding to our claims 3 and 4. Yes, but the eleme n ts of 
claims 3 and 4 are not taught by Primak. 

F. Examiner says Primak teaches the server metafarm meantime- 
to- failure. (Server processing or CPU capacity, CPU load, a 
number of existing connections at Primak column 4, lines 10-20). 
But, Primak does not apply to "Meta farms". 

6. Regarding claim 7, Examiner says Primak teaches the server 
metafarm availability and • • • the availability information of 
its associated server, at Primak column 4 lines 27-40. Again, 
note Metafarms are not addressed by Primak. 

H. Examiner says Primak teaches the redundancy factor that 

should be minimi zed the entire range could result in 30% of 

the connection values falling within the server's sub-range, as 
seen in Primak column 5, lines 10-20. Also, the server metafarm 
meantime-to-failure seen at Primak column 4, lines 10-20. Note, 
however, how Applicant's Figs. 2 and 3 allow proper selection of 
Redundancy Factors in a manner not taught by Primak. 

I. Examiner says Primak teaches the value of the optimization 
parameters (value from 0 to 32,000) at Primak column 4, lines 39- 

68) and a value for the optimization criterion assigned a 

sub -range about 30%, seen in Primak column 5 lines 25-40, and 

Primak teaching that of making an evaluation decision if the 
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connection value of the SYN packet is within the server's 
assigned range, in Primak column 4, lines 50-60. This does not 
correlate with Applicant's teaching of Figs. 2 and 3, nor does 
Applicant require a SYN packet. 

J. Examiner says Primak teaches the decision to stop the 
procedure if the number of server farms in the configured multi- 
servers (metafarm?) is determined citing the connection value 

of the SYN packet being within the server's assigned sub-range — 
— and the associated load-balancing module 12 forwarding the SYN 
packet to the server to accept the connection request from the 
client, at Primak column 4, lines 50-60. 

Applicant is not involved with such a SYN packet, as 
required by Primak. 

Applicant now hopes that Examiner will realize the 
outstandingly different conditions which are involved when there 
is a huge multiplicity of server farms (metafarms) and there is a 
huge number of users, that is to say 10,000 or more users or 
greater. It is under these types of conditions that Applicant 
has developed his present method and system. 

It is to be noted that Examiner has cited the Adelman 
reference, U.S. Patent 6,006, 259. However, it is unclear from 
Examiner ' s statements exactly what portion of Adelman that 
Examiner cites as being of value in helping teach the substance 
of Applicant's configuration, if Adelman were combined with 
Primak . 

In view of the prior discussion, and the 
inapplicability of the Primak reference and the Adelman reference 
in regard to Applicant's purposes and functionality for 
optimizing the parameters for metafarms (multiple server farms) 
in conjunction with huge client base operators, such as 10,000 or 
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more, it should be understood that the present application does 
make a distinctive contribution to the state-of-the-art and 
should be regarded as a whole in its entirety, and not just a 
mere conglomeration of other functionalities from other 
references . 



Examiner consider the extant claims and subsequently provide a 
Notice of Allowance therefor. 



I hereby certify that this paper (along with any paper referred to as being attached or enclosed) 
is being deposited with the United States Postal Service on the date shown below with sufficient 
postage as first class mail in an envelope addressed to: MAIL STOP AMENDMENT/ Commissioner for 
Patents, P.O. Box 1450, Alexandria, VA 22313-1450. _ 



In this regard, it is now respectfully requested that 



Respectfully submitted. 
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